In the field of product designing, a person skilled in designing creates specifications which are considered optimum for a certain design object based on knowledge, his/her patterns of thinking, and so on obtained from long years of experience.
In late years, it is concerned that the majority of such knowledge or the like in a design process will be lost accompanying retirements of such skilled persons. Accordingly, there are several attempts to transform skilled persons' knowledge and so on into data. However, the design process may be repeated due to trial and error, change of requirement, and/or the like, and thus the design process is difficult to be described appropriately by a conventional process description method of sequential execution type.
Accordingly, the present inventor has suggested a method of modeling a product development process for automobiles, home electric appliances, and the like, as one of attempts to provide a platform for transforming a working (thinking) process when designing by such skilled persons or the like into data (see, for example, Non-patent document 1). In Non-patent document 1, on the basis of “designing” as a work of deciding the shape, structure, or the like of a product in a series of product development processes, which are “plan”, “design”, “designing”, “test/verification”, “production preparation”, and “production”, the “plan” and “design”, which are upstream works of “designing”, are ranked as work processes for deciding requirements for “designing”. The “test/verification” and “production preparation”, which are downstream works of “designing”, are ranked as work processes for verifying the functionality and productivity of contents decided in design works. The designing, the upstream of designing, and the downstream of designing are assumed as three processes: (a) work of recognizing requirements for designing, (b) designing definition work, and (c) verification work of designing, and individual works forming them are assumed as (a) “requirement”, (b) “definition”, and (c) “confirmation” respectively, whereby a method of describing these works and relations between works is proposed as RDC model.
Non-patent document 1: “Requirement Definition Confirmation Model for the Engineering Process Decomposition”, Toshihiko Nakazawa, Journal of Japan Society for Design Engineering, Vol. 38, No. 12, December Issue, 2003.
The RDC model can solve difficulties that occur when describing a production development process including trial-and-error and circulation of works by a conventionally existing expression method of sequential processing type such as a flowchart. However, the RDC model is developed for capturing explicit works in product development processes, and thus design process recording, as a part thereof, involves many oversights.
A major part of product development is a process of “designing”. Furthermore, a major part of works of designing is an intellectual activity performed in designer's mind. This process is performed along with progress of designing, and will be lost without remaining as a record. In such an implicit design process, there exist sections of: recognition of requirements (recognition of requirement specifications or the like) that is “requirement” in the narrow sense; design definition work (deciding the shape and structure of a product) that is “definition” in the narrow sense; and verification work (verification with drawing, calculation, and CAE analysis, or the like) that is “confirmation” in the narrow sense. However, in the RDC model, the “requirement”, “definition”, and “confirmation” in the broad sense in the aforementioned product development process and the “requirement”, “definition”, and “confirmation” in the narrow sense in the design process are considered without distinction. Works such as the “requirement”, “definition”, and “confirmation” in the narrow sense in this design process are mostly performed unconsciously by a designer, and it is difficult by the conventional RDC model to sort out such unrecognized works.
For example, as shown in FIG. 28, when there is a design process of deciding a definition 202 that a certain part is “fixed with four screws” so as to satisfy a requirement 201 “not coming off when dropped”, the designer can recognize relatively easily that there exists a design process of “deciding the number of screws”.
However, when thinking logically, before a work of deciding the number of screws (definition 202) there ought to be processes such as a work of “selecting an optimum fixing method” like a work 203 of “adopting screws as a fixing method”, and a work of “grasping requirements for the fixing method to satisfy” such as a work 204 of “recognizing that the part does not come off when pulled with a static load of 100 N”, so as to satisfy the requirement 201.
However, when the designer thinks it is a matter of course to use screws to fix this part (for the reason that it has been so in conventional products), there occurs a situation that decision making to use the screws is performed without being recognized. In such a situation, in the RDC model, the process of “deciding an optimum fixing method” is not recorded clearly.
There may further exist many design processes in which the designer decides a structure and shape of a product directly from vague requirements. For example, in the above-described example of fixing a part, the “number of screws” is decided immediately from the requirement “not coming off when dropped”. Normally, in this example, a process of deciding the fixing force of the part should exists before deciding the type and the number of screws. In this manner, in a design process that should be elaborate, there exist many rough decision making works, and it can be imagined that such rough processes deteriorate the quality of design. However, in the RDC model, it is difficult to recognize, faithfully and reliably, implicit works as described above.
The present invention is made in view of the above-described problems, and an object thereof is to obtain a design process recording apparatus which allows to describe works which are not recorded in the RDC model, such as “requirement”, “definition”, and “confirmation” in the narrow sense in a design process, a data structure, a computer program, and a design process recording method for recording design processes by a designer as data.